“Reuse” of services is one of the key benefits of provided by a service-oriented architecture (SOA). A service registry oftentimes is thought of as one of the fundamental entities of a SOA involved in enabling such reuse. Conventionally, the “registry” in a SOA is the place where all metadata or data information about services is maintained within an organization or group of organizations. Standard registries include, for example, UDDI (Universal Discovery Description and Integration), ebXML (Electronic Business using eXtensible Markup Language), and the like. In general, and more broadly speaking, anything that maintains “services” can be called a registry. For example, the Open Service Gateway Initiative (OSGi) has its own service registry for services running within an OSGi container.
Organizations oftentimes will want to combine multiple registries. For example, companies may be confronted with the problem of how to combine multiple registries when, for example, they have merged with other companies and the specific resources are managed in their own separate registries. Another example of when an organization might want to combine multiple registries relates to SOA adaptation, e.g., when two or more departments in a given organization want to combine their services through one registry.
Registry federation is the process of combining a group of registries such that when any one registry is accessed, the services related to any of them can be returned. Registry federation thus may in some instances help address the above-described and/or other challenges oftentimes faced by different companies. UDDI and some other current registries provide mechanisms that enable federation. Such conventional mechanisms generally rely on there being a homogeneous environment in which all of the registries essentially “talk” to using the same protocol.
Unfortunately, however, heterogeneity is something that oftentimes cannot be avoided in the real world. Heterogeneity in computer systems and/or registries can be caused by any number of different factors. Such factors may include some or all of the following and/or other scenarios:    1. A company acquires another company and cannot standardize using one registry as part of the merger, at least in the short-term;    2. SOA adaption is carried out at the department level rather than at the company level and, as a result, different solutions have been chosen because of the requirements being focused on a specific department or a specific few departments, rather than all departments within a company;    3. A company wants to amalgamate its registry with those of its partners to provide a single view of the services that are be provided;    4. A company wants to host a public registry over different types of registries; and/or    5. A company wants to facilitate reuse by merging standard registries like UDDI, ebXML, etc., with other registries like OSGi, ESB (Enterprise Service Bus), a home-grown registry, etc., potentially within a single view.
Registry federation typically is accomplished in one of two ways, e.g., as shown in FIGS. 1 and 2. According to a first approach, e.g., as shown in FIG. 1, when a user makes a request from a client device 102a, 102b, or 102c, the request is sent to all registries 104a, 104b, 104c, . . . , 104n, participating in federation via a gateway registry 106. The result from each registry 104a, 104b, 104c, . . . , 104n, is consolidated at the gateway registry 106 and ultimately is sent back to the user.
According to a second approach, e.g., as shown in FIG. 2, a so-called master gateway registry 206 pulls the services/assets from the federated registries 104a, 104b, 104c, . . . , 104n, and saves a link or a copy of the services in the master gateway registry 206. This pre-fetched data is served when a user makes a request from a client device 102a, 102b, or 102c. 
Although these approaches may be successfully implemented in some scenarios, further enhancements are still desirable. For instance, conventional approaches generally involve a common language (such as UDDI) or ontology. Referring to FIG. 1, for example, the implementation of a common language such as UDDI, for example, would involve the registry gateway being a UDDI gateway and would rely on each participant using the UDDI protocol, even if the individual participants are not registries of that type. This arrangement is shown, for example, in FIG. 3, where a client 102a communicates with the registries 104a and 104b through the UDDI gateway registry 106, which generates UDDI requests that are processed through UDDI protocol layers 108a and 108b respectively provided to the registries 104a and 104b. It is noted that a UDDI protocol layer 104b is provided for the registry 104b, even though that registry is an ebXML registry. It thus will be appreciated that complexity is introduced as more and more registries are added, especially if more and more registries of more and more different types are provided. It also might not be feasible in all instances to provide a UDDI layer to the individual registries, e.g., if one or more public registries are involved, if a user does not have control over all registries, etc.
Conventional approaches also tend to have issues with scalability and/or performance, e.g., because potentially massive amounts of data may need to be pre-fetched and stored. Although the storage concern might be alleviated in part when links to actual services are stored, a tight coupling between the gateway registry and the actual services in the various registries is created, which can be problematic in some instances. For instances, the tight coupling may be problematic in public registries where registries can join and leave federation at potentially any time and for potentially any reason.
Thus, it will be appreciated that there is a need in the art for improved federating registries in a service-oriented architecture environment.
One aspect of certain example embodiments relates to techniques enabling heterogeneous registries (including ActiveDirectory, UDDI, ebXML, OSGi, ESB, and/or other different registry types) to federate via a scalable real-time mechanism.
Another aspect of certain example embodiments involves a network topology in which a translation protocol layer is moved into a gateway registry, which aids in providing a scalable heterogeneous federation of registries. In other words, certain example embodiments advantageously are able to unite multiple, heterogeneous registries using a gateway and translation technique.
Another aspect of certain example embodiments involves enabling heterogeneous registries (including ActiveDirectory, UDDI, ebXML, OSGi, ESB, and/or other different registry types) to be handled in a generic way, at least from the client perspective. Certain example embodiments thus may advantageously provide an interface enabling registry type independent querying, while also insulating the clients from code changes even when a change to a registry is mandated, when a new registry or the same or different type is added, etc.
Still another aspect of certain example embodiments involves the definition of an intermediate layer in which queries are translated for each specific registry type.
In certain example embodiments, a method of maintaining a federation of target registries is provided. The target registries are separated from at least one client device via a master gateway registry (that optionally includes a plurality of translation modules) hosted on a computer system including a processor and a memory. A request for a service from the at least one client device is received at the master gateway registry, with the request being in a first format. The request is translated into translated requests of one or more second formats, with the one or more second formats being different from the first format and being selected so as to match protocols natively supported by the target registries. The translated requests are electronically transmitted to the target registries. In response to the electronic transmission to the target registries, responses are received from the target registries in the one or more second formats. The responses from the one or more second formats are translated into translated responses in the first format. The translated responses are electronically transmitted from the master gateway registry to the at least one client device.
According to certain example embodiments, the at least one client device is permitted to contact the target registries only indirectly and through the master gateway registry, and vice versa.
According to certain example embodiments, translations are performed at the master gateway registry using the processor of the computer system. And additionally, or in the alternative, according to certain example embodiments, translations may be performed in accordance with configured mappings as between the first format and the one or more second formats, with the mappings being stored to a non-transitory computer readable storage medium accessible by the master gateway registry. Translations may be performable as between formats supporting, for example, ActiveDirectory, UDDI, ebXML, OSGi, ESB, webservice, proprietary protocols, and/or the like. For instance, translations from UDDI protocol based messages to SOAP messages for webservice protocol support may be selectively generated, and vice versa.
According to certain example embodiments, the target registries are accessible through at least two slave gateway registries that each is in communication with the master gateway registry. The at least two slave gateway registries are arranged hierarchically, e.g., in successive tiers.
In certain example embodiments, there is provided a method of maintaining a federation of target registries, with the target registries being separated from at least one client device via a master gateway registry. A request to add a new target registry to the federation is received. Parameters of services offered by the new registry that are to be exposed to the at least one client device are identified. The identified parameters are mapped to corresponding parameters exposed through the master gateway registry. The mapping provides instructions as to how messages in a first format for a first protocol usable by the at least one client device are to be translated into corresponding messages in a second format for a second protocol usable by the new target registry, and vice versa. The first and second formats and/or the first and second protocols are different from one another. The mapping is stored to a non-transitory computer readable storage medium. The new registry is deployed in a group of registries based on one or more characteristics associated with the new registry. The newly deployed registry is enabled and so may begin accepting requests from and serving replies to the at least one client device, through the master gateway registry, in connection with the mapping.
In certain example embodiments, there are provided non-transitory computer readable storage mediums tangibly storing instructions that, when executed by at least one processor of a system, perform the above-described and/or other methods.
Similarly, in certain example embodiments, a computer system including a processor, a memory, and a non-transitory computer readable medium, is configured to execute computer functions for accomplishing the above-described and/or other methods. For instance, in certain example embodiments, a computer system including a processor, a memory, and a non-transitory computer readable medium, may host a master gateway registry configured to at least perform the above-described and/or other methods.
These aspects and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.